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Requirements of a Quality of Service (QoS) Solution for Mobile IP 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
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Abstract 


Mobile IP ensures correct routing of packets to a mobile node as the 
mobile node changes its point of attachment to the Internet. 
However, it is also required to provide proper Quality of Service 
(QoS) forwarding treatment to the mobile node’s packet stream at the 
intermediate nodes in the network, so that QoS-sensitive IP services 
can be supported over Mobile IP. This document describes 
requirements for an IP QoS mechanism for its satisfactory operation 
with Mobile IP. 
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1. Introduction 


Mobile IP is a technology that allows a "mobile node" (MN) to change 
its point of attachment to the Internet while communicating with the 


"correspondent node" (CN) using IP. The formal description of Mobile 
IP can be found in [1, 6]. Mobile IP primarily addresses the correct 
routing of packets to MN’s current point of attachment with the 
Internet. 


It is also essential to provide proper Quality of Service (QoS) 
forwarding treatment to the packets sent by or destined to MN as they 
propagate along different routes in the network due to node mobility. 
This document will identify the requirements that Mobile IP places on 
an IP QoS mechanism. 


1.1. Problem Statement 


When an MN using Mobile IP undergoes handover from one access router 
to another, the path traversed by MN’s packet stream in the network 


may change. Such a change may be limited to a small segment of the 
end-to-end path near the extremity, or it could also have an end-to- 
end impact. Further, the packets belonging to MN’s ongoing session 


may start using a new care-of address after handover. Hence, they 
may not be recognized by some forwarding functions in the nodes even 
along that segment of the end-to-end path that remains unaltered 
after handover. Finally, handover may occur between the subnets that 
are under different administrative control. 
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In the light of this scenario, it is essential to establish proper 
QoS support for the MN’s packet stream along the new packet path. 


1.2. An approach for solving the QoS problem in Mobile IP 


There are four important steps involved in solving the QoS problem 
for Mobile IP. They are as follows: (1) List the requirements that 
Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS 
solutions against these requirements, (3) Decide if current solutions 
need to be extended, or if new ones need to be defined, and (4) 
Depending on the result of step 3, define new solutions or fix the 
old ones. 


Of these, the first step, i.e., the requirements step, is addressed 
in this document. The last three steps are not dealt with here in 
detail. However, so as to create useful insight into the Mobile IP 
QoS problem, at times this document highlights the shortcomings of 
some well known current proposals for establishing QoS support for 
the packet stream in the network, when directly used with Mobile IP. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 [2]. 


3. Requirements of a QoS solution for Mobile IP 


This section describes the requirements for a QoS solution for its 
satisfactory operation with Mobile IP. Conversely, note that only 
Mobile IP-specific requirements are described here. We do not assume 
any particular version (4 or 6) of IP while describing the 


requirements. Solutions can be designed for IPv4 and IPv6 
independently, or a single solution can be designed to work with both 
versions. 


In this document, we assume that the target access router for MN’s 
handover is already pinned down by other protocols. For example, 
Seamoby working group has started work on the candidate access router 
discovery protocols [7]. Thus, any QoS-capability specific 
negotiations that may affect the handover decision are outside the 
scope of QoS solution as such, rather need to be performed by 
candidate and target access router selection protocols. 
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3.1. Performance requirements 
1. Minimize the interruption in QoS at the time of handover: 


At the time of handover, interruption in QoS would occur if the 
packets sent by or destined to the MN arrive at the intermediate 
node in the new packet path without that node having information 
about their QoS forwarding requirement. Then, those packets will 
receive default forwarding treatment. Such QoS interruption MUST 
be minimized. A good metric for this performance is the number of 
packets that may potentially get served with the "default" QoS at 
the time of handover. The number of such packets MUST be 
minimized. 


As an example, this performance metric is computed in [8] for the 
case of end-to-end RSVP signaling [3] with Mobile IPv6. It is 
shown there that when the end-to-end path of packets changes at 
large after handover or when the care-of address changes after 
handover, OPWA (One Pass With Advertisement) model of reservation 
used by RSVP causes the latency of about one round-trip time 
between the MN and the CN before QoS can be established along the 
new packet path. In other words, the packets using the new care- 
of address that would be released by the MN or the CN during one 
round-trip time, after these nodes are ready to use the new care- 
of address, may get default forwarding treatment at the 
intermediate nodes. Such a latency in QoS programming may be 
acceptable at the time of session initiation, but it is not 
acceptable in the middle of an active session as would be the case 
with handover. 


2. Localize the QoS (re)establishment to the affected parts of the 
packet path in the network: 


In many cases, handover changes only a small segment of the end- 
to-end path of MN’s packet stream near the extremity. Then, the 
QoS mechanism MUST limit the extent of QoS (re)establishment to 
the affected segment of the end-to-end path only. 


However, note that handover may sometimes cause the end-to-end 
path of MN’s packet stream in the network to change at large. 
This may happen, for example, in the case of handover between 
different administrative domains. If the QoS mechanism used to 
establish QoS support for the MN’s packet stream along the new 
packet path in the network is based on the explicit end-to-end 
provisioning as such, it MUST perform so at the time of such 
handover. 
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When the care-of address changes upon handover, it may be required 
to perform some signaling even over the unchanged part of the 
end-to-end path if the path contains any QoS mechanisms that use 
IP address as a key to forwarding functions. Examples are FILTER 
SPECs in the IntServ nodes or packet classifiers at the edges of 
DiffServ networks. However, double provisioning of resources over 
the unchanged part of the packet path MUST be avoided. 


Note that the QoS signaling protocol such as RSVP [9] can localize 
the QoS signaling to the affected parts of the end-to-end path if 
the care-of address does not change upon handover. However, if 
the care-of address changes upon handover, RSVP as currently 
defined [4] fails to localize the QoS signaling. In addition, it 
will cause double reservations on the part of end-to-end path that 
remains unchanged after handover. 


3. Releasing after handover the QoS state (if any) along the old 
packet path: 


The QoS mechanism MUST provide some means (explicit or timer- 
based) to release any QoS state along the old packet path that is 
not required after handover. It is desirable that the unwarranted 
QoS states, if any, along the old path are released as quickly as 
possible at the time of handover. Note that, during handover, the 
MN may not always get a chance to send explicit tear down message 
along the old path because of the loss of link layer connectivity 
with the old access router. 


3.2. Interoperability requirements 
1. Interoperability with mobility protocols: 


A number of mobility protocols that are complementary to Mobile IP 
are already defined or may be defined in future in IETF, 


particularly in Mobile IP and Seamoby working groups. Examples 
are fast handover [10, 11], localized mobility management [12, 
13], context transfer [5] etc. The QoS mechanism for Mobile IP 


SHOULD take advantage of these mobility protocols for the 
optimized operation. However, the QoS scheme MUST have provisions 
to accomplish its tasks even if one or more of these mobility 
protocols are not used. 


2. Interoperability with heterogeneous packet paths as regards QoS 
paradigms: 


The new path after handover, of the MN’s packet stream, may 


traverse network domains employing different QoS paradigms 
compared to those along the old path. The QoS mechanism for 
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Mobile IP SHOULD be able to establish proper QoS forwarding 
treatment for the MN’s packet stream along the packet paths 
deploying different QoS paradigms (best current practices), ina 
manner consistent with the QoS mechanism deployed along those 
paths. 


As an illustration, suppose that the MN is currently attached to 
an access router which is the edge router of a DiffServ network, 
and that the packet classifier and traffic policer for the MN’s 
flows are presently programmed in this access router. Now, 
suppose that the MN needs to be handed over to the access router 
which is at the edge of an IntServ network. The new access 
network would expect the exchange of RSVP messages so that proper 
QoS forwarding treatment can be established for the MN’s packet 
stream in that access network. QoS mechanism for Mobile IP SHOULD 
have provisions to handle such heterogeneity as regards the QoS 
mechanisms deployed along different packet paths. 


3.3. Miscellaneous requirements 
1. QoS support along multiple packet paths: 


After MN undergoes handover from one access router to another, 
potentially, there could be multiple paths over which MN’s packet 
may propagate. Examples of these path are: route-optimized path 
between the MN and its CN, triangle route via Home Agent (HA), 
temporary tunnel between old and new access routers, reverse 
tunnel from the new access router (Foreign Agent) to HA etc. A 
QoS mechanism SHOULD be able to support QoS along the different 
potential packet paths. However, whether all paths are supported 
or only a subset of them is supported will be determined by 
external mechanisms such as mobility management, policy, location 
privacy requirement and so on. Further, the same QoS mechanism 
may not be able to support all these paths. 


2. Interactions with wireless link-layer support for QoS: 


Since a vast number of devices using Mobile IP will be connected 
to the Internet via wireless links, the QoS mechanism for Mobile 
IP MAY provide some information to the wireless link layers for 

them to support the required QoS. 


An example scenario that may benefit from such information is that 
of the two UDP streams associated with the same media, but 
requiring different levels of error protection at the wireless 
link layer due to certain characteristics of their respective 
encoding schemes. The packets of these two streams are equally 
delay sensitive (so as to maintain playout synchronization at the 
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receiver), and hence, may be treated equally (as regards queuing) 
by IP layer. But they may need to be transmitted on wireless 
channels of different error characteristics (say different FEC 
coding or power levels). 


The QoS information included for the benefit of wireless link 
layers SHOULD be such that it is meaningful both ways: to 
applications that reside over IP so that they can choose the IP 
service of certain QoS characteristics and to wireless link QoS 
managers so that they can then map this information to the details 
of lower layer mechanisms and their parameters. 


In the example scenario described above, such a QoS information 
could be expressed as the acceptable loss rate of IP packets in 
the UDP stream. This parameter enables the UDP application to 
choose the IP service having QoS that matches its requirements, 
and it also enables the wireless link QoS managers to choose the 
right wireless channel to transmit the packets of this UDP stream. 


3.4. Standard requirements 


The QoS solution for Mobile IP SHOULD satisfy standard requirements 
such as scalability, security, conservation of wireless bandwidth, 
low processing overhead on mobile terminals, providing hooks for 
authorization and accounting, and robustness against failures of any 
Mobile IP-specific QoS components in the network. While it is not 
possible to set quantitative targets for these desirable properties, 
the QoS solution MUST be evaluated against these criteria. 


4. Security Considerations 


The QoS (re)establishment triggered by node mobility MUST be guarded 
against security attacks. Such attacks could be launched by 
malicious nodes that spoof the QoS signaling to make it appear to the 
intermediate nodes that the MN has undergone handover. Such an 
attack could disrupt the QoS offered to MN’s ongoing sessions as the 
intermediate nodes may then tear down the QoS along some segments of 
the true packet paths between MN and CN. The malicious nodes may 
also request a reduced level of QoS or supply fake packet 
classifiers, thereby affecting QoS over some segments (e.g., that do 
not get affected by the spoofed handover) of the true packet paths 
between MN and CN. Further, network resources may be wasted or used 
in an unauthorized manner by the malicious nodes that spoof MN’s 
handover. To prevent this, QoS mechanism MUST provide means for 
intermediate nodes to verify the authenticity of handover-induced QoS 
(re) establishment. 
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Recommendation 


In this document, we described the requirements for a QoS solution 
for its satisfactory operation with Mobile IP. The expectation is 
that the appropriate working group will use this requirements 
document to provide a QoS solution for Mobile IP. 


Acknowledgment 


I would like to acknowledge the participants of the mailing list that 
was set up to discuss the above requirements. Their contributions 
and active participation in the discussion on the mailing list were 
very useful in the preparation of this document. Special thanks are 
due to, in alphabetical order, Brian Carpenter (IBM), Marc Greis 
(Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael 
Thomas (Cisco) for their input during the preparation of this 
document. 


References 
1. Normative References 


[1] Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344, 
August 2002. 


[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
Levels", BCP 14, RFC 2119, March 1997. 


[3] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, 
M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 
Framework for Integrated Services Operation over Diffserv 
Networks", RFC 2998, November 2000. 


[4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 
Specification", RFC 2205, September 1997. 


[5] Kempf, J., Ed., "Problem description: Reasons for performing 
context transfers between nodes in an IP Access Network", RFC 
3374, September 2002. 


.2. Informative References 


[6] Johnson, D., Perkins, C. and J. Arkko, "Mobility support in 
IPv6", Work in Progress, May 2003. 


Chaskar Informational [Page 8] 


RFC 3583 Mobile IP QoS Requirements September 2003 


[7] Trossen, D., et al., "Issues in Candidate Access Router 
discovery for seamless IP handoffs", Work in Progress, October 
2002. 


[8] Chaskar, H. and R. Koodli, "QoS support in Mobile IP version 6", 
IEEE Broadband Wireless Summit (Networld+Interop), May 2001. 


[9] Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work 
in Progress, February 2001. 


[10] MIPv4 Handoffs Design Team, "Low latency handoffs in Mobile 
IPv4", Work in Progress, June 2002. 


[11] Koodli, R., Ed., "Fast handovers for Mobile IPv6", Work in 
Progress, March 2003. 


[12] Williams, C., Ed., "Localized mobility management requirements", 
Work in Progress, March 2003. 


[13] Soliman, H., et al., “Hierarchical MIPv6 mobility management 
(HMIPv6)", Work in Progress, October 2002. 


8. Authors’ Addresses 
The working group can be contacted via the current chair: 
John Loughney 
Nokia Research Center 
11-13 Italahdenkatu 
00180 Helsinki 
Finland 
EMail: john.loughney@nokia.com 
Questions about this memo can be directed to the editor: 
Hemant Chaskar 
Nokia Research Center 
5 Wayside Road 
Burlington, MA 01803, USA 


Phone: +1 781-993-3785 
EMail: hemant.chaskar@nokia.com 


Chaskar Informational [Page 9] 


RFC 3583 Mobile IP QoS Requirements September 2003 


9. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Chaskar Informational [Page 10] 


